Evolution of Object Behavior using

CompositeEquipment abstract void visit (Visitor v) void net() {....} void discount() {....} Card void visit (Visitor v) { v.atCard(this); } void visit (Visitor v) Cabinet { v.atCabinet(this); for (int i=0; i<numparts; i++) parts[i].visit(v); } Fig. 6. Composite Equipment Pattern erations to perform during composite-object traversal. A composite is a structural pattern that represents a wholepart hierarchy, and is modeled using the aggregation relation. For example, the class structure in Figure 6 describes a containment hierarchy for computer equipment, which may contain other equipment as parts. The visitor pattern may be used to reduce the number of operations directly embedded within a class, thus preventing class de nitions from becoming cluttered. Visitors group related operations performed on multiple classes (which need not be related through inheritance) together into one program component, supporting a collaborative, task-based style of programming. Collaborative styles have become very popular through such mechanisms as Contracts [10], Subjects [11], and Propagation Patterns [12], [13]. Figure 7 contains a standard visitor design, similar to the example presented by Gamma et al [1]. An example task computes the total cost of computer equipment, based on accumulating the net price of simple equipment (Card, Drive, FloppyDisk) and the discount price of composite equipment (Chassis, Cabinet, Bus). Another task might be to accumulate a list of equipment contained within a computer. Each of these tasks can be implemented with a traversal and a visitor. A traversal implements a generic navigation algorithm, simply accessing each equipment object contained within a composite object by recursively following aggregation relations. The traversal is implemented by de ning a visitmethod in each concrete equipment class. The visit method simply tells the visitor that it has encountered a particular class instance. For example, the visit method for the Card class sends the visitor an atCard message, passing the self reference as an argument. The visit method in the Cabinet class will send an atCabinet message to the visitor as well as traverse the equipment objects reachable through its parts relation. The relation between the Equipment and Visitor classes takes the form of a method invocation. The Visitor class will have a default empty atXXX method for each concrete class XXX. This default behavior may be overridden in subclasses of Visitor to perform a task-speci c behavior. For example, the Pricing visitor will override the default inherited methods to add the net price of simple equipment and the discount price of composite equipment, while the Inventory visitor will override the inherited methods to accumulate a list of equipment. The visitor design points out some of the di culties of supporting dynamic behavior with languages such as Java and C++. The appropriate behavior to execute when an object is encountered during traversal depends on both the type of the object being visited as well as the type of the visitor. The code for the visitor is quite awkward, primarily due to the single dispatch binding mechanism of Java and C++. Although the same behavior is performed by the inventory visitor when either a Card or Chassis object is encountered, the limitation of the single dispatch mechanism still requires an atXXX method to be de ned for each concrete class XXX . Code reuse is not achieved through in-